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^invention concerne un procede de securisation dynamique d'un 
langage du type a donnees typees, notamment pour un systeme embarque a 
puce electronique. 

L'invention concerne encore un systeme embarque a puce 
5 electronique pour la mise en ceuvre du procede. 

Dans le cadre de I'invention, le terme "systeme embarque" doit etre 
compris dans son sens le plus general. II concerne notamment toutes sortes 
de terminaux legers munis d'une puce electronique, et plus particulierement 
les cartes a puce proprement dites. La puce electronique est munie de 
10 moyens d'enregistrement et de traitement de donnees numeriques, par 
exemple un microprocesseur pour ces derniers moyens. 

Pour fixer les idees, et sans que cela limite en quoi que ce soit sa 
portee, on se placera ci-apres dans le cas de ^application preferee de 
I'invention, a savoir les applications a base de cartes a puce, sauf mention 
15 contraire. 

De meme, bien que divers langages informatiques, tels les 
langages "ADA" ou "KAMEL" (tous deux etant des marques deposees), sont 
du type dit a donnees ou objets types, un des langages les plus utilises dans 
le domaine prefere de I'invention etant le langage de type objet "JAVA" 
20 (marque deposee), ce langage sera pris comme exemple ci-apres, pour 
decrire en detail le procede de I'invention. 

Enfin, le terme "securisation" doit lui aussi etre compris dans un 
sens general. Notamment, il concerne aussi bien ce qui a trait au concept de 
confidentiality des donnees manipulees qu'au concept d'integrite, materielle 
25 et/ou logicielle, des composants presents dans le systeme embarque. 

Avant de decrire plus avant Invention, il est tout d'abord utile de 
rappeler brievement les principals caracteristiques du langage "JAVA", 
notamment dans un environnement du type carte a puce. 

Ce dernier langage presente en particulier Tavantage d'etre 
30 multiplateformes : il suffit que la machine dans laquelle s'execute 
Tapplication ecrite en langage "JAVA" soit munie d'un minimum de 
ressources informatiques specifiques, notamment d'une piece de logiciel 



appele "machi ne virtuelle JAVA' pour Interpretation d'une suite de 
sequences d' "opcodes' 1 ^instructions de 8 bits, appelees "bytecode" ou M p- 
code" (pour "program code" ou code programme). Le "p-code" est enregistre 
dans des positions de memoire des moyens d'enregistrement de donnees 
precites. Plus precisement, dans le cas du langage "JAVA", la zone occup6e 
par les positions de memoire, d'un point de vue logique, se presente sous 
une configuration connue sous le nom de pile. 

Dans le cas d'une carte a puce, celle-ci integre la "machine virtuelle 
JAVA" (enregistree dans ses moyens de memoire) et fonctionne en 
interpretant un langage base sur la sequence d'opcodes precitee. Le code 
executable ou "p-code" resulte d'une compilation prealable. Le compilateur 
est agence pour que le langage transforme obeisse a un format determine et 
respecte un certain nombre de regies fixees a priori. 

Les "opcodes" peuvent recevoir des valeurs d'elements les suivants 
dans une sequence du "p-code", ces elements sont alors appeles 
parametres. Les opcodes peuvent aussi recevoir des valeurs en provenance 
de la pile. Ces elements constituent alors des operandes. 

Selon une autre caracteristique du langage "JAVA", il est mis en 
oeuvre des elements connus sous les noms de "classes" et de "methodes". 
Lors de I'execution d'une methode donnee, la machine virtuelle retrouve le 
"p-code" correspondant. Ce "p-code" identifie des operations specifiques a 
effectuer par la machine virtuelle. Une pile particuliere est necessaire pour 
le traitement de variables dites locales, d'operations arithmetiques ou pour 
revocation d'autres methodes. 

Cette pile sert de zone de travail pour la machine virtuelle. Pour 
optimiser les performances de la machine virtuelle, la largeur de la pile est 
generalement fixee pour un type primitif donne. 

Dans cette pile deux grands types d'objets peuvent etre manipules : 
des objets de type dit "primitif, ceux connus sous les denominations 

"int (pour entier long : 4 octets), "short ' (pour entier court : 2 octets), 

"dyfe" (octet), "boolean" (objet booleen) ; et 
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- des objets de type dit "reference" (tableaux d'objets de type primitif, 
instances de classes). 

La difference fondamentale entre ces deux types d'objets est que 
seule la machine virtuelle attribue une valeur a des objets de type reference 
5 et les manipule. 

Les objets references peuvent etre vus comme des pointeurs vers 
des zones memoires de la carte a puce (references physiques ou logiques). 

Le langage "JAVA", dont les principales caracteristiques viennent 
d'etre succinctement rappelees, se prete particulierement bien aux 
10 applications mettant en jeu des interconnexions avec le reseau Internet et 
son grand succes est d'ailleurs lie au fort developpement des applications 
Internet. 

D'un point de vue securite, il presente aussi un certain nombre 
d'avantages. Tout d'abord, le code executable ou "p-code" resulte d'une 

15 compilation prealable. Le compilateur peut done etre agence, comme il a ete 
indique, pour que le langage transforme obeisse a un format determine et 
respecte un certain nombre de regies fixees a priori. 

Une de ces regies est qu'une application donnee soit confinee a 
Tinterieur de ce qui est appele une "sand box" (ou "boite noire"). Les 

20 instructions et/ou donnees associees a une application determinee sont 
memorisees dans des positions de memoire des moyens d'enregistrement 
de donnees. Dans le cas du langage "JAVA", d'un point de vue logique, la 
configuration de ces moyens d'enregistrement de donnees prend la forme 
d'une pile. Le confinement dans une "sand box" signifie en pratique que les 

25 instructions precitees ne peuvent pas adresser des positions memoires en 
dehors de celles affectees a ladite application, sans y etre autorisees 
expressement. 

Cependant, une fois charge en memoire, des problemes de securite 
peuvent se poser si le "p-code" a ete altere ou si son format n'a pas 
30 respecte les specifications de la machine virtuelle. Aussi, dans Tart connu, 
notamment lorsqu'il s'agit duplications, par exemple des "applets" 
(appliquettes), telechargees via le reseau Internet, le code compile, e'est-a- 



dire le "p-code" est verifie par la machine virtuelle. Cette derniere est 
habituellement associee a un navigateur de type "WEB" dont est muni le 
terminal connecte au reseau Internet. Pour ce faire, la machine virtuelle est 
elle-meme associee a une piece de logiciel particuliere ou verificateur. 

Cette verification peut s'effectuer en mode dit M off-line u f c'est-a-dire 
hors connexion, ce qui ne penalise pas le traitement de Tapplication, 
notamment d'un point de vue cout de communication. 

On est ainsi sur, apres que la verification soit effectu6e, que le "p- 
code M n'est pas endommage et est conforme au format et aux regies 
preetablis. On est aussi sur, dans ces conditions, que lors de Texecution du 
M p-code M , il n'y aura pas de deterioration du terminal dans le quel il 
s'execute. 

Cependant, ce procede n'est pas sans inconvenients, en particulier 
dans le cadre des applications visees preferentiellement par I'invention. { 

Tout d'abord, le verificateur precite necessite a lui seul une quantite 
de memoire relativement importante, de I'ordre de plusieurs MO. Cette 
valeur elevee ne presente pas de problemes particuliers si le verificateur est 
enregistre dans un micro-ordinateur ou un terminal similaire disposant de 
ressources memoires elevees. Cependant, lorsque Ton envisage d'utiliser un 
terminal de traitement de donnees possedant des ressources informatiques 
plus limitees, a fortiori une carte a puce, il n'est pas envisageable, d'un point 
de vue pratique, compte tenu des technologies actuellement disponibles, 
d'implementer le verificateur dans ce type de terminal. 

On doit egalement noter que la verification est d'un type que Ton 
peut qualifier de M statique M , car effectuee une fois pour toute, avant 
Texecution du M p-code M . Lorsqu'il s'agit d'un terminal du type micro- 
ordinateur, notamment lorsque ce dernier est maintenu deconnecte lors de 
I'execution du "p-code" verifie au prealable, cette derniere caracteristique ne 
pose pas de problemes particuliers. En effet, il n'existe pas de risques 
importants, d'un point de vue securite, car le terminal reste habituellement 
sous le controle de son operateur. 



Tel n'est pas le cas pour un systeme embarque mobile, notamment 
pour une carte a puce. En effet, si le "p-code", meme verifie, est ensuite 
charge dans les moyens d'enregistrement de donnees de la carte a puce, il 
peut subir a posteriori des alterations. En general, la carte a puce, ce par 
5 nature, n'est pas destinee a demeurer en permanence dans le terminal a 
partir duquel I'application a ete chargee. A titre d'exemple non limitatif, la 
carte a puce peut etre soumise a un rayonnement ionisant qui altere 
physiquement des positions de memoire. II est possible egalement d'alterer 
le "p-code" au moment de son telechargement dans la carte a puce, a partir 
10 du terminal. 

II s'ensuit que, si le "p-code" est altere, notamment dans un but 
malveillant, il est possible d'effectuer une operation dite de "dump" 
(duplication) de zones de memoires et/ou de mettre en peril le bon 
fonctionnement de la carte a puce. II devient ainsi possible, par exemple, et 

15 malgre la disposition dite de "sand box" precitee, d'avoir acces a des 
donnees confidentielles, ou pour le moins non autorisees, ou d'attaquer 
I'integrite d'une ou plusieurs applications presentes sur la carte a puce. 
Enfin, si la carte a puce est connectee au monde exterieur, les 
dysfonctionnements provoques peuvent se propager a I'exterieur de la carte 

20 a puce. 

^invention vise a pallier les inconvenients des precedes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles. 

L'invention se fixe pour but un procede de securisation dynamique 
^applications en langage du type a donnees typees dans un systeme 
25 embarque. 

Elle se fixe egalement pour but un systeme pour la mise en ceuvre 
de ce procede. 

Pour ce faire, selon une premiere caracteristique, un element 
d'information binaire comprenant un ou plusieurs bits, que Ton appellera ci- 
30 apres "element ^information de type", est associe a chaque objet manipule 
par la machine virtuelle, dans le cas du langage "JAVA" precite. De fa^on 
plus generate, un element d'information de type est associe a chaque 
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donnee typee manipulee dans un langage donne, du type a objets ou 
donnees types. 

Selon une autre caracteristique, les elements d'information de type 
sont stockes physiquement dans des zones de memoire particulieres des 
moyens de memorisation du systeme embarque a puce electronique. 

Selon une autre caracteristique encore la machine virtuelle, toujours 
dans le cas du langage "JAVA" verifie lesdits elements ^information de type 
lors de certaines operations d'execution du "p-code", telles la manipulation 
d'objet dans la pile, etc., operations qui seront precisees ci-apres. De fa?on 
plus generale egalement, pour un autre langage, le processus est similaire 
et il est procede a une etape de verification des elements d'information de 
type. On constate done que, de fagon avantageuse, ladite verification est 
d'un type que Ton peut appeler dynamique, puisqu'effectuee en temps reel 
lors de Interpretation ou de I'execution du code. 

La machine virtuelle, ou ce qui en tient lieu pour un langage autre 
que le langage "JAVA" verifie, en continu et avant ladite execution d'une 
instruction ou d'une operation, que Telement d'information de type 
correspond bien au type attendu de I'objet ou de la donnee type a manipuler. 
Lorsqu'un type incorrect est detecte, des mesures securitaires sont prises 
afin de proteger la machine virtuelle et/ou d'empecher toutes operations non 
conformes et/ou dangereuses pour Tintegrite du systeme embarque a puce 
electronique. 

Selon une premiere variante de realisation supplemental du 
procede selon I'invention, lesdits elements d'information de type sont 
egalement utilises avantageusement pour permettent la gestion de piles de 
largeurs variables, ce qui permet d*optimiser I'espace memoire du systeme 
embarque a puce electronique, dont les ressources de ce type sont, par 
nature, limitees, comme il a ete rappele. 

Selon une deuxieme variante de realisation supplemental, 
cumulable avec la premiere, les elements d'information de type sont 
egalement utilises, en y adjoignant un ou plusieurs bit(s) d'information 
supplementaire(s), utilises comme "drapeau" ("flags" selon la terminologie 
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anglo-saxonne), pour marquer les objets ou les donnees typees. Ce 
marquage est alors utilise pour indiquer si ces derniers elements sont 
utilises ou non, et dans ce dernier cas, s'ils peuvent etre effaces de la 
memoire, ce qui permet egalement de gagner de la place memoire. 
5 L'invention a done pour objet principal un procede pour I'execution 

securisee d'une sequence d'instructions d'une application informatique se 
presentant sous la forme de donnees typees enregistrees dans une 
premiere serie d'emplacements determines d'une memoire d'un systeme 
informatique, notamment un systeme embarque a puce electronique, 
10 caracterise en ce que des donnees supplementaires dites elements 
d'information de type sont associes a chacune desdites donnees typees, de 
maniere a specifier le type de ces donnees, en ce que lesdits elements 
d'information de type sont enregistres dans une deuxieme serie 
d'emplacements de memoire determines de ladite memoire de systeme 
15 informatique, et en ce que, avant I'execution d'instructions d'un type 
predetermine, il est procede a une verification en continu, prealable a 
I'execution d'instructions predetermines, de la concordance entre un type 
indique par ces instructions et un type attendu indique par lesdits elements 
d'information de type enregistres dans ladite deuxieme serie d'emplacement 
20 de memoire, de maniere n'autoriser ladite execution qu'en cas de 
concordance entre lesdits types. 

L'invention a encore pour objet un systeme embarque a puce 
electronique pour la mise en oeuvre de ce procede. 

L'invention va maintenant etre decrite de facon plus detaillee en se 
25 referant aux dessins annexes, parmi lesquels : 

les figures 1A a 1G illustrent les principales etapes d'une 
execution correcte d'un exemple de "p-code" dans une memoire a 
pile associee a des zones de memoire specifiques stockant des 
donnees dites elements d'information de type selon l'invention ; 
30 - les figures 2A et 2B illustrent schematiquement des etapes 

d'execution de ce meme code, mais contenant une alteration menant 
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a une execution incorrecte et une detection de cette alteration par le 
procede de 1'invention ; et 

la figure 3 illustre schematiquement un systeme comprenant 
une carte a puce pour la mise en ceuvre du proc6de selon 
I'invention. 

Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 
placera ci-apres dans le cadre de Implication preferee de 1'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un systeme embarque a puce 
electronique integrant une machine virtuelle "JAVA" pour interpretation de 
"p-code". 

Comme il a ete rappele dans le preambule de la presente 
description, lors de I'execution d'une methode donnee, la machine virtuelle 
retrouve le "p-code 11 correspondant. Ce "p-code" identifie des operations 
specifiques a effectuer par la machine virtuelle. Une pile particuliere est 
necessaire pour le traitement de variables dites locales, d'operations 
arithmetiques ou pour invocation d'autres methodes. 

La pile sert de zone de travail pour la machine virtuelle. Pour 
optimiser les performances de la machine virtuelle, la largeur de la pile est 
generalement fixee pour un type primitif donne. 

Comme il a ete egalement rappele, dans cette pile deux grands 
types d'objets peuvent etre manipules : 

des objets de type dit "primitif', ceux connus sous les denominations 
"int % (pour entier long : 4 octets), "short ' (pour entier court : 2 octets), 
"byte" (octet), "boolean" (objet booleen) ; et 

des objets de type dit "reference" (tableaux d'objets de type primitif, 
instances de classes). 

C'est ce dernier type d'objets qui pose le plus de probleme, d'un 
point de vue securite, puisqu'il existe des possibilites, comme indique 
precedemment, de les manipuler de fa^on artificielle et de creer ainsi des 
dysfonctionnements de natures diverses. 

lis existent plusieurs types d 1 "opcodes", et notamment : 



- la creation d'un objet de type primitif (par exemple les opcodes 
denommes "bipush" ou "iconsf') ; 

I'execution d'operations arithmetiques sur des objets de type primitif 
(par exemple les "opcodes" denommes "iadcf ou "sadd') ; 

- la creation d'un objet reference (par exemple les "opcodes" 
denommes "neW, "newarray" ou "anewarray"). 

- la gestion de variables locales (par exemple les "opcodes" denommes 
"aloacf', "ifoacf' ou "istore") ; et 

- la gestion de variables de classes (par exemple les "opcodes" 
denommes "getstatic_a" ou "putfield_r). 

Chaque "opcode" qui utilise des objets places en pile est type afin 
de s'assurer que son execution puisse etre controlee. Generalement la(les) 
premiere(s) lettre(s) des "opcodes" indique(nt) le type utilise. A titre 
d'exemple, et pour fixer les idees, (la ou les premiere(s) lettre(s) etant 
graissee pour mettre en evidence cette disposition), on peut citer les 
"opcodes" suivants : 

"aload" pour les objets references ; 

"iload' pour les entiers ; et 

- "iaload' pour les tableaux d'entiers. 

Dans ce qui suit, par mesure de simplification la "machine virtuelle 
JAVA" sera appelee JVM. 

Selon une premiere caracteristique du procede selon I'invention, 
des elements d'information de type sont stockes dans une zone memoire 
sous la forme, chacun, d'un ou de plusieurs bits. Chacun de ces elements 
d'information de type caracterise un objet manipule par la JVM. On associe 
notamment un element d'information de type a : 

- chaque objet empile dans la zone de donnee de la pile ; 

- chaque variable locale (variable dont la portee ne depasse pas le 
cadre d'une methode) ; et 

- a chaque objet de ce qui est appele le "heap", c'est-a-dire une zone 
de memoire stockant les objets dits "reference", chaque tableau et 
chaque variable globale. 
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Cette operation peut etre appelee "typage" des objets. Selon une 
deuxieme caracteristique du procede de invention, la JVM verifie le typage 
dans les cas suivants : 

lorsqu'un "opcode' 1 manipule un objet stocke dans la pile ; 

recupere un objet dans la zone du "heap" ou dans celle des variables 

locales pour le placer en pile ; 

modifie un objet dans la zone du "heap" ou dans celle des variables 
locales ; et 

lors de invocation d'une nouvelle methode, lorsque les operandes 
sont compares a la signature de la methode. 

Selon une autre caracteristique du procede de invention, la JVM 
verifie, avant I'execution des operations ci-dessus, que leurs types 
correspondent bien a celui attendu (c'est-a-dire ceux donnes par les 
"opcode" a effectuer). 

Dans le cas de la detection d'un type incorrect, des mesures 
securitaires sont prises afin de proteger la JVM et/ou d'empecher toutes 
operations illegales ou dangereuses pour integrite du systeme, tant d'un 
point de vue logique que materiel. 

Pour mieux expliciter le procede selon invention, on va maintenant 
le detainer en considerant un exemple particulier de code source en langage 
"JAVA". 

On suppose egalement que la JVM est associee a une pile de 32 
bits comportant au plus 32 niveaux et supportant les types primitifs (par 
exemple "int\ "short", "byte", "boolean" et "object reference") 

Le typage de la pile, selon Tune des caracteristiques de 1'invention, 
peut alors etre realise a Taide d'elements d'information de type de longueur 
3 bits, conformement a la TABLE I placee en fin de la presente description. 
Les valeurs portees dans la TABLE I sont naturellement arbitraires. D'autres 
conventions pourraient etre prises sans sortir du cadre de invention. 

Le code source "JAVA" qui va etre considere ci-apr§s a titre 
d'exemple particulier est le suivant : 
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Source "JAVA" (1) : 



Public void method(){ 
int[] buffer; 
buffer=new int[2] ; 



//Declaration 



// creation d'un tableau d'entiers de 2 



elements 



buffer[1]=5 ; 
} 



// initialisation du tableau avec la valeur 5 



Apres un passage dans un compilateur approprie, un fichier 
"classe" contenant le M p-code M (2) correspondant au code source ci-dessus 
(1) est obtenu. II se presente comme suit : 

" p-code " (2) : 



iconst_2 


// Push int constant 2 


newarray 


TJNT 


astore_1 


int[] buffer 


aload_1 


int[] buffer 


iconst_1 


// Push int constant 1 


iconst_5 


// Push int constant 5 


iastore 




return 





Comme il est bien connu de I'homme de metier, les trois premieres 
lignes correspondent a la creation du tableau precite (voir code source (1)). 
Les cinq dernieres lignes correspondent a ('initialisation de ce tableau 

On va maintenant illustrer en detail les etapes d'une execution 
correcte du "p-code" ci-dessus. Puisque le M p-code M est un langage de type 
interprets, les lignes successives sont lues les unes apres les autres et les 
etapes precitees correspondent a I'execution de ces lignes, avec 
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eventuellement I'execution d'iterations et/ou de branchements. Dans ce qui 
suit, les differentes lignes de code sont graissees pour les mettre en 
evidence. 

Execution correcte : 

Etape 1 : "iconst_2" 

La figure 1 A illustre de fa?on schematique I'etape d'execution de ce 
"p-code". On a represents, sous la reference 1, la memoire du systeme 
embarque a puce electronique (non represente). De fagon plus precise, 
cette memoire 1 est divisee en quatre parties principals, deux etant 
communes a Tart connu : la zone dite "zone data" (donnees) 2a et la zone 
dite "zone variable locale" 3a. Ces zones, 2a et 3a, constituent la pile 
proprement dite de la machine virtuelle "JAVA" (JVM) que Ton appellera ci- 
apres par simplification "pile de la JVM\ 

A ces zones sont associees des zones de memoire, 4a et 5a, 
respectivement, specifiques a I'invention, que Ton appellera zones de 
"Typage". Selon un des aspects de I'invention, les zones de memoire, 4a et 
5a, sont destinees a stocker des elements d'information de type (de 
longueur 3 bits dans I'exemple decrit) associes aux donnees stockees dans 
les zones 2a et 3a, respectivement, dans des emplacements de memoire en 
relation biunivoque avec les emplacements de memoire de ces zones. 
L'organisation logique de ces zones de memoire est du type dit "pile" comme 
rappele. Aussi, elles ont ete representees sous la forme de tableaux de 
dimensions cx/, avec c nombre de colonnes et / nombre de lignes, c'est-a- 
dire la M hauteur M de la pile ou niveau (qui peut varier a chaque etape de 
Texecution d'un "p-code"). Dans I'exemple, c=4 pour les zones "zone data" 
2a et "zone variable locale" 3a (chaque colonne correspondant a une 
position de memoire de 4 octets, soit au total 32 bits), et c=3 pour les zones 
de "typage", Aa et 5a, (chaque colonne correspondant a une position de 
memoire de 1 bit). Sur la figure 1A, le nombre de lignes represente (ou 
numero de niveau : 1 a 32 maximum dans Texemple decrit) est egal a 2 
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pour toutes les zones de memoire. Chacune des zones de memoire, 2a a 
5a, constitue done une pile elementaire. 

On doit bien comprendre cependant que, physiquement, les 
positions de memoires precitees peuvent etre realisees a base de divers 
5 circuits electroniques : cellules de memoire vive, registres, etc. De meme, 
elles ne sont pas forcement contigues dans I'espace memoire 1 . La figure 
1A ne constitue qu'une representation schematique de I'organisation logique 
en piles de la memoire 1 . 

L' "opcode" a executer pendant cette premiere etape n'a ni 
10 parametre, ni operande. La valeur entiere 2 (soit "0002") est placee dans la 
pile : au niveau 1 (ligne inferieure dans I'exemple) de la zone 2a. La zone de 
"Typage" correspondante 4a est mise a jour. 

D'apres les conventions de la TABLE I, la valeur "inf (entier) "000" 
(en bits) est placee dans la zone de "Typage" 4a, egalement au niveau 1 
15 (ligne inferieure). Aucune valeur n'est placee dans la "zone variable locale" 
3a. II en est de meme de la zone de "Typage" correspondante 5a. 

Etape 2 : newarray TJNT 

L'etape correspondante est illustree par la figure 1B. 

Les elements communs a la figure 1A portent les memes references 
20 numeriques et ne seront re-decrits qu'en tant que de besoin. Seule la valeur 
litterale associee aux valeurs numeriques est modifiee. Elle est identique a 
celle de la figure correspondante, soit b dans le cas de la figure 1B, de 
maniere a caracteriser les modifications successives des contenus des 
zones de memoire. II en sera de meme pour les figures suivantes 1C a 1G. 
25 U "opcode" a executer pendant cette deuxieme etape a pour 

parametre le type de tableau a creer (soit type "inf). 

Cet "opcode" a pour operande une valeur qui doit etre de type "inf, 
correspondant a la taille du tableau a creer (soit 2). 

La verification de la zone de "Typage" (a I'etat 4a) indique un type 
30 correct. L'execution est done possible. 

Un objet reference est cree dans la "Pile JVM" : par exemple la 
valeur (arbitraire) de quatre octets "1234" est placee dans les positions de 
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memoire de la "zone variable locale" (niveau 1). PuisqiTil s'agit d'un objet de 
type reference, la valeur "100" (en bits) est placee dans la zone de , Typage M 
correspondante 5b (niveau 1). 

Aucune valeur n'est placee dans la zone de memoire 3b t ni dans la 
5 zone de "Typage" 5b. 

Etape 3 : astore_1 intQ buffer 

Cette etape est illustree par la figure 1C. 

L' "opcode" a pour operande une valeur qui doit etre de type "Objet 
reference". La verification de la zone de "Typage" (a I'etat 4b) indique un 
10 type correct, ^execution est done possible. 

L'objet reference est deplace vers la "zone variable locale" 3c : 
emplacement 1 (niveau 1 ). 

Les zones de "Typage", 4c et 5c sont mise a jour : la valeur H 100" 
(en bits) est deplacee du niveau 1 de la zone Ac vers le niveau 1 de la 
15 zone 5c. 

Etape 4 : aload_1 into buffer 

Cette etape est illustree par la figure 1 D. 

Cet "opcode" a pour objet d'empiler l'objet reference "1234", stocke 
dans la "zone variable locale" 3d, au niveau 1 de la "zone data" 2d, e'est-a- 
20 dire dans les positions de memoire de la ligne inferieure de cette zone. 

La verification de la zone de "Typage" (a I'etat 5c) indique un type 
correct. Uexecution est done possible. 

L'objet reference "1234" est place dans la "zone data" 2d. 

Les zones de "Typage" Ad et 5d sont mises a jour et stockent toutes 
25 deux, dans les emplacements de memoire correspondants, la valeur "100" 
(en bits), representative d'un type "Objet reference". 

Etape 5 : iconst_1 // Push int constant 1 

Cette etape est illustree par la figure 1 E. 

U "opcode" a executer pendant cette etape n'a ni parametre ni 
30 operande. La valeur entiere 1 (soit "0001") est placee dans la pile : 
emplacement 2 (niveau 2) de la "zone data" 2e. La zone de "Typage" 
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correspondante 4e est mise a jour, egalement au niveau 2 (le niveau 1 reste 
inchange : valeur "1000"). La valeur "inf (entier) "000" (en bits) est placee 
dans la zone de "Typage" A e (niveau 2). Les zones 3e et 5e restent 
inchangees. 

5 Etape 6 : iconst_5 // Push int constant 5 

Cette etape est illustree par la figure 1 F. 

L' "opcode" a executer pendant cette etape n'a ni parametre ni 
operande. La valeur entiere 1 (soit "0001") est placee dans la pile : niveau 3 
de la "zone data" If. La zone de "Typage" correspondante Af est mise a jour, 
10 egalement au niveau 3 (les niveaux 1 et 2 restent inchanges : valeurs "1000" 
et "000" respectivement). La valeur "inf (entier) "000" (en bits) est placee 
dans la zone de "Typage" Af. Les zones 3f et 5f restent inchangees. 
Etape 7 : iastore 

Cette etape est illustree par la figure 1G. 
15 Get "opcode" a pour operande une valeur de type "int", un index de 

type "inf et un objet reference de type tableau. 

La verification de la zone de "Typage" (a I'etat Af : niveau 3) indique 
un type correct. L'execution est done possible. 

La valeur est stockee dans I'objet reference a I'index donne. 
20 Etape 7 : return 

Cet "opcode" indique la fin de la methode, la pile doit alors etre 

vide. 

En considerant de nouveau le meme "p-code" (voir (2), obtenu 
apres compilation du code source (1)), on va maintenant detainer un 
25 exemple d'execution incorrecte. 

Execution incorrecte : 
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A I'etape que I'on nommera 4' (correspondant a I'etape 4 : figure 1D). II est 
suppose que le "p-code" a ete altere et que I' "opcode" : 

"aload_1 int Q buffer" , 
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a ete remplace, par exemple, par I' M opcode M suivant : 

"iipush 0x5678", 
instruction dans laquelle " 0x M indique une valeur hexadecimale. 

Comme illustre par la figure 2A, cet "opcode", de type objet de 
5 reference, stocke au niveau 1 de la "zone variable locale" 3a\ a pour objet 
d'empiler un entier de valeur "5678" dans la pile, dans la "zone data" 2'a. 

La zone de "Typage" 4a* va etre mise a jour II s'ensuit que les 
niveaux 1 des zones de "Typage", 4a' et 5a', vont tous deux contenir la 
valeur "100" (en bits), c'est-a-dire une valeur associee a un "Objet 
10 reference". Cette configuration particuliere est illustree par la figure 2A. 

L'execution se poursuit normalement comme dans le cas 
precedemment illustre par reference aux figures 1 E et 1 F. 
Etape 5' : iconst_1 // Push int constant 1 
Etape 6' : iconst_5 // Push int constant 5 
15 L/etat des zones de la "pile de la JWW", "zone variable locale" 3b' et 

"zone data" 2b\ est illustre par la figure 2B. de fa<?on plus precise la "zone 
data" 2b 1 enregistre, au niveau 1 , la valeur entiere "5678", au niveau 2, la 
valeur entiere "0001" et au niveau 3, la valeur entiere "0005". La "zone 
variable locale" 3a 1 est restee inchangee. II en est de meme de la zone de 
20 "Typage" correspondante 5a'. Par contre, la zone de "Typage" Ab % est mise a 
jour et les valeurs suivantes sont enregistrees aux niveaux respectifs 1 a 3 : 
"100", "000" et "000" (en bits). 
Etape 7' : iastore 

Cet "opcode" a pour operande une valeur de type "int\ un index de 
25 type "int 1 et un objet reference de type tableau. 

La verification de la zone de "Typage" (niveau 1 de la zone, a Petat 
4&) indique que le code detecte est incorrect. En effet, un entier ("int 9 ; code 
"000") est attendu a la place d'un "Objet reference" (code "100"). 

La JVM detecte done la presence d'un "opcode" illegal menagant la 
30 securite du systeme. ^execution normale de la sequence destructions en 
cours est interrompue et remplacee par Texecution destructions 
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correspondent a des mesures securitaires pre-programmees : signal 
d'alerte, etc. 

On a suppose jusqu*a present que la largeur (ou taille) de la "pile de 
la JVM" ; que ce soit celle de la "zone data" ou la "zone variable locale", etait 
5 fixe, ce qui est generalement le cas dans Tart connu. Dans I'exemple decrit, 
on a suppose que chaque emplacement de memoire compte quatre octets 
(soit 32 bits). Cependant, une telle disposition s'avere penalisante en terme 
de capacite de memoire. En effet, d'une application logicielle a I'autre, voire 
a I'interieur d'une meme application, le nombre d'octets necessaire pour 

10 chaque instruction est variable. Comme il a ete indique, I'agencement les 
piles elementaires des "zone data" et "zone variable locale" telles 
qu'illustrees par les figures 1A a 1G, ou 2A a 2B, ne represented qu'une vue 
logique de I'espace memoire 1. II est done tout a fait possible de conserver 
une architecture logique du type pile, meme si les emplacements de 

15 memoire, successifs ou non, sont de longueurs variables, voire meme si les 
differentes positions (cellules) de memoire sont physiquement dispersees. 

Aussi, selon une premiere variante supplemental du procede 
selon Pinvention, les elements d'information de type permettent aussi de 
determiner la largeur instantanee necessaire, en positions de memoire, des 

20 zones de la "pile de la JVM". II suffit, pour ce faire, que les codes enregistres 
dans les zones de "Typage" de la memoire soient associes, en tout ou 
partie, a une information caracterisant la largeur de la pile precitee. A titre 
d'exemple non limitatif, il peut s'agir de bits supplementaires, ajoutes aux 
codes de typage, ou d'une combinaison de bits non utilisee de ces codes. 

25 Dans le premier cas, si la largeur de la pile peut varier, toujours a titre 
d'exemple, entre 1 et 4 octets, il suffit de 2 bits supplementaires pour 
caracteriser les largeurs suivantes : 



Configuration binaire 


00 


01 


10 


11 


Largeur en octets 


1 


2 


3 


4 
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Cette disposition, qui permet d'optimiser Tespace memoire en 
fonction des applications a executer, conduit a un gain de place de memoire 
substantial, ce qui constitue un avantage appreciable lorsqu'il s'agit de 
dispositifs, telle notamment une carte a puce, dont les ressources de 
stockage sont limitees par nature. 

Selon une deuxieme variante de realisation du procede selon 
I'invention, il est egalement possible d'utiliser les elements ^information de 
type pour indiquer si un objet est encore utilise (c'est-a-dire doit etre 
conserve) ou peut etre efface de la "zone variable locale 1 '. En effet, au bout 
d'un certain nombre d'operations, un objet donne enregistre dans cette zone 
n'est plus utilise. Le laisser en permanence constitue done une perte inutile 
d'espace memoire. 

A titre d'exemple non limitatif, on peut ajouter un bit d'information 
aux codes enregistres dans les zones de "Typage", faisant fonction de 
drapeau, ou "flag" selon la terminologie anglo-saxonne. L'etat de ce bit 
indique alors si I'objet doit etre conserve (car encore utilise) ou peut etre 
efface, et le marque comme tel. Les conventions arbitraires suivantes 
peuvent etre adoptes : 

- etat logique "0" = objet utilise 

- etat logique "1" = objet pouvant etre efface 

Cette disposition, que Ton peut qualifier de mecanisme de type 
"garbage collector" (ou "ramasse-miettes") permet aussi un gain en espace 
memoire. 

Naturellement, les dispositions propres aux deux variantes de 
realisation supplementaires qui viennent d'etre decrites peuvent etre 
cumulees. 

La figure 3 illustre schematiquement un exemple d'architecture de 
systeme informatique a base duplications de carte a puce pour la mise en 
oeuvre du procede selon Tinvention qui vient d'etre decrit. 

Ce systeme comprend un terminal 7, qui peut etre relie ou non a des 
reseaux exterieurs, notamment au reseau Internet Rl, par un modem ou tous 
moyens equivalents 71. Le terminal 7, par exemple un micro-ordinateur, 
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comprend notamment un compilateur 9. Le code peut etre compile a 
Texterieur du terminal pour donner un fichier dit " Class" (compilateur "JAVA" 
vers "Class"), c'est ce fichier qui est telecharge par un navigateur Internet, le 
micro-ordinateur comprend lui un convertisseurr qui donne un fichier dit 
5 "Cap" ("Class" vers "Cap"). Ce convertisseur reduit notamment la taille du 
fichier "Class" pour permettre de le charger sur une carte a puce. Une 
application quelconque, par exemple telechargee via le reseau Internet Rl et 
ecrite en langage "JAVA" est compilee par le compilateur 9 et chargee, via 
un lecteur de carte a puce 70 dans les circuits de memoire 1 de la carte a 

10 puce 8. Celle-ci integre, comme il a ete rappele, une machine virtuelle 
"JAVA (JVM) 6 capable d'interpreter le "p-code" issu de la compilation et 
charges dans la memoire 1. On a egalement represents differentes piles de 
memoire : les zones "zone data" 2 et "zone variable locale" 3, ainsi que les 
zones de typage, 4 et 5, ces dernieres specifiques a ['invention. La carte a 

15 puce 8 comprend egalement des moyens classiques de traitement de 
donnees relies a la memoire 1, par exemple un microprocesseur 80. 

Les communications entre la carte a puce 8 et le terminal 7, via le 
lecteur 70, d'une part, et entre le terminal 7 et le monde exterieur, par 
exemple le reseau Internet Rl } via le modem 71, d'autre part, s'effectuent de 

20 fagon egalement classique en soi, et il n'y pas lieu de les decrire plus avant. 

A la lecture de ce qui precede, on constate aisement que I'invention 
atteint bien les buts qu'elle s'est fixes. 

Elle permet une execution securisee d'une suite destructions d'une 
application ecrite langage du type a donnees typees se deroulant dans une 

25 memoire a architecture de type pile. Le degre de securisation eleve est 
obtenu notamment du fait que la verification du code est effectuee de fagon 
dynamique, selon un des aspects de Tinvention. 

Cette disposition permet en outre, au prix d'une augmentation 
minime du temps de traitement, de se passer d'un verificateur necessitant 

30 des ressources de memoire importantes. Ce type de verificateur ne peut 
d'ailleurs convenir, dans la pratique, aux applications preferees de 
Tinvention. 



20 



II doit etre clair cependant que I'invention n'est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
les figures 1A a 1G, 2A a 2B et 3. 

De meme, bien que Tinvention s'applique plus particulierement a un 
langage de type objet, et plus particulierement au "p-code" du langage 
"JAVA", obtenu apres compilation, elle s'applique a un grand nombre de 
langage mettant en oeuvre des donnees typees, tels les langages U ADA M ou 
M KAMEL M rappeles dans le preambule de la presente description. 

Enfin, bien que Tinvention soit particulierement avantageuse pour 
des systemes embarques a puce electronique, dont les ressources 
informatiques, tant de traitement de donnees que de stockage de ces 
donnees, sont limitees, notamment pour des cartes a puce, elle convient 
parfaitement, a fortiori, pour des systemes plus puissants. 
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TABLE I 



Prefixe 


Type 


Code 


/ 


'7/7f 


000 


s 


"Short" 


001 


b 


"Byte" 


010 


z 


"Boolean" 


011 


a 


"Object Reference" 


100 
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REVEND1CAT1QNS 

1- Procede rout I'execution securisee d'une sequence d'instructions d'une 
application informatique se pr6sentant sous la forme de donn6es typees 
enregistrees dans une premiere serie d'emplacements determines d'une 
memoire d'un systeme informatique, notamment un systeme embarque a 
puce electronique, caracterise en ce que des donnees supplementaires 
dites elements d'information de type sont associes^a chacune desdites 
donnees typ6es, de maniere a specifier le type de ces donnees, en ce 
que lesdits elements d'information de type sont enregistres dans une 
deuxieme serie ^emplacements de memoire determines (4, 5) de ladite 
memoire (1) de systeme informatique (8), et en ce que, avant I'execution 
d'instructions d'un type predetermine, il est procede a une verification en 
continu, prealable a I'execution d'instructions predetermines, de la 
concordance entre un type indique par ces instructions et un type attendu 
indique par lesdits elements d'information de type enregistres dans ladite 
deuxieme serie d'emplacement de memoire (4, 5), de maniere n'autoriser 
ladite execution qu'en cas de concordance entre lesdits types. 

2. Procede selon la revendication 1 , caracterise en ce que chacun desdits 
elements d'information de type est constitue par une suite de bits 
enregistres dans des emplacements de memoire de ladite deuxieme serie 
(4, 5), en correspondance biunivoque avec des emplacements de 
memoire de ladite premiere serie (2, 3) dans lesquels sont enregistrees 
desdites donnees typees associees, et dont la configuration est 
representative d'un desdits types de donnees typees. 

3. Procede selon la revendication 1, caracterise en ce que lesdites 
instructions etant celles d'une application ecrite en langage "JAVA" 
(marque deposee), lesdites donnees typees sont constitutes par des 
objets types, en ce que ledit systeme informatique integre une piece de 
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logicielle elite machine virtuelle "JAVA" (5) manipulant lesdits objets types, 
en ce que, lesdits emplacements de memoire (2-5) de ladite memoire (1) 
du systeme informatique (8) etant organises en piles comportant un 
nombre maximum de niveaux determine, chaque niveau constituant un 
desdits emplacements de memoire, lesdits objets types sont enregistres 
dans au moins une premiere pile elementaire dite zone de donnees (2) et 
un deuxieme pile elementaire dite zone de variables locales (3), et en ce 
que lesdits elements d'information de type sont repartis dans deux piles 
elementaires supplementaires (4, 5) en relation biunivoque avec lesdites 
premiere (2) et deuxieme (3) piles elementaires, de maniere a specifier le 
type desdits objets associes enregistres dans lesdites zones de donnees 
(2) et de variables locales (3). 

4. Procede selon la revendication 1 , caracterise en ce que lorsque ladite 
concordance n'est pas realisee, ('execution de ladite sequence 
d' instructions est interrompue et remplacee par I'execution destructions 
correspondant a des mesures securitaires pre-programmees 

5. Procede selon la revendication 3, caracterise en ce que lesdits 
elements d'information de type sont associes a des elements 
d'information supplementaires determinant la taille desdits emplacements 
de memoires desdites piles (2, 3) enregistrant lesdits objets types, de 
maniere a rendre variable la taille desdites piles, en fonction desdits 
objets a manipuler. 

6. Procede selon la revendication 3, caracterise en ce que lesdits 
elements d'information de type sont associes a des elements 
d'information supplementaires, dits drapeaux, de maniere a marquer 
lesdits objets qui leur sont associes et a indiquer s'ils doivent etre 
conserves dans lesdites piles (2, 3) ou peuvent etre effaces. 

7. Systeme embarque a carte a puce electronique comprenant des 
moyens de traitement informatique de donnees et des moyens de 
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memoire pour I'execution securisee d'une sequence destructions d'une 
application informatique se presentant sous la forme de donnees typ6es 
enregistrees dans une premiere serie d'emplacements determines d'une 
memoire d'un systeme informatique, caracterise en ce que lesdits moyens 
de memoire (1) comprennent une deuxieme serie d'emplacements 
determines (4, 5) pour I'enregistrement de donnees supplementaires dites 
elements d'information de type, associes a chacune desdites donnees 
typees, de maniere a specifier le type de ces donnees, et des moyens de 
verification (6) permettant une verification en continu, prealable a 
I'execution destructions predetermines, de la concordance entre un 
type indique par ces instructions et un type indique par lesdits elements 
d'information de type, de maniere n'autoriser ladite execution qu'en cas 
de concordance entre lesdits types. 

8. Systeme selon la revendication 7, caracterise en ce que, ladite 
premiere serie d'emplacements determines de ladite memoire (1) du 
systeme embarque a puce electronique (8) etant organisee en piles 
comportant un nombre maximum de niveaux determine, chaque niveau 
constituant un desdits emplacements de memoire, lesdites donnees 
typees sont enregistrees dans au moins une premiere pile elementaire 
dite zone de donnees (2) et une deuxieme pile elementaire dite zone de 
variables locales (3), et en ce que ladite deuxieme serie d'emplacements 
de memoire est aussi organisee en piles elementaires (4, 5), en relation 
biunivoque avec lesdites premiere (2) et deuxieme (3) piles elementaires. 

9. Systeme selon la revendication 8, caracterise en ce que lesdits 
elements d'information de type enregistres dans ladite deuxieme serie 
d'emplacements de memoire (4, 5) sont associes a des elements 
d'information supplementaires determinant la taille desdits emplacements 
de memoires desdites piles (2, 3) enregistrant lesdites donnees typees. 

10. Systeme selon la revendication 7, caracterise en ce que ledit systeme 
embarqu§ est une carte a puce (8). 
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